Skip to content

Conversation

@ValerianRey
Copy link
Contributor

@ValerianRey ValerianRey commented Jan 8, 2026

  • Move accumulation code to _accumulation.py
  • Rename Accumulate to AccumulateGrad
  • Add AccumulateJac
  • Add jac_to_grad
  • Remove aggregation responsibility from backward and mtl_backward
  • Remove Aggregate transform (move its code to jac_to_grad.py)
  • Simplify _disunite_gradient (use split instead of manually looping)
  • Add utils/asserts.py file to check things about .jac or .grad fields
  • Update tests and usage examples according to all those changes
  • Add changelog entry

@ValerianRey ValerianRey added the feat New feature or request label Jan 8, 2026
@ValerianRey ValerianRey self-assigned this Jan 8, 2026
@ValerianRey
Copy link
Contributor Author

ValerianRey commented Jan 8, 2026

We have something a bit tricky: both jac_to_grad and the AccumulateGrad transform depend on the code from _accumulation.py.

To reuse some code in two different packages (utils and autojac), without making one depend on the other, we would need another protected package just for this code. So IMO we could:

  • Have a the _accumulation.py code somewhere else in torchjd (either in a standalone protected python file or in a protected accumulation module).
  • Duplicate some accumulation code.
  • Live with the fact that autojac depends on utils and utils depends on aggregation.

@ValerianRey
Copy link
Contributor Author

Lastly, it's very annoying to have this Pylance error all over the place:

Cannot access attribute "jac" for class "Tensor"
  Attribute "jac" is unknown

I'm not sure how we could reliably stop showing this error, or even use a custom tensor that would properly fix this.

@PierreQuinton
Copy link
Contributor

Lastly, it's very annoying to have this Pylance error all over the place:

Cannot access attribute "jac" for class "Tensor"
  Attribute "jac" is unknown

I'm not sure how we could reliably stop showing this error, or even use a custom tensor that would properly fix this.

I think this is just because all this is bad design. We made it more torch compatible, and this is the price. Pylance is right, there is not field jac in Tensors.

@ValerianRey
Copy link
Contributor Author

I think this is just because all this is bad design. We made it more torch compatible, and this is the price. Pylance is right, there is not field jac in Tensors.

Yeah but there are still ways to make it much cleaner. I'm working on something.

@PierreQuinton
Copy link
Contributor

Yeah but there are still ways to make it much cleaner. I'm working on something.

I think we should keep in mind that we would like the users to have a good typing experience. It would be nasty to make them use .jac fields if they get typing errors.

@ValerianRey
Copy link
Contributor Author

Yeah but there are still ways to make it much cleaner. I'm working on something.

I think we should keep in mind that we would like the users to have a good typing experience. It would be nasty to make them use .jac fields if they get typing errors.

Well, they should rarely need to use these .jac fields themselves. If they want access to the jacobians, they should use autojac.jac.

@PierreQuinton
Copy link
Contributor

right, that's very good, and if they do, they should get some amount of warning. You can delete the discussion if you want (annoying that we cannot have a thread).

@ValerianRey ValerianRey marked this pull request as ready for review January 12, 2026 18:09
@PierreQuinton this was a big issue that we didn't spot earlier. I don't think the jacobian_matrix can be a view of the concatenated jacobians, so I think that having both the individual matrices + the combined matrix alive at the same time means using double memory. With this _free_jacs call much ealier, if the garbage collector is reactive, we shouldn't have this issue of doubling the peak memory usage for no reason. I think we should check that this PR doesn't introduce a huge memory efficiency regression. Can't merge without doing that.
These functions really are wrappers around assert_close, so we'd like them to always also take the parameters of assert_close, even if those change in the future, and to have the same default values. So I think kwargs is justified here. Also it's not user facing so the lack of documentation of the expected types will not be visible.
@ValerianRey ValerianRey changed the title feat: Use .jac fields feat(autojac): Use jac_to_grad to aggregate .jac fields Jan 14, 2026
@ValerianRey ValerianRey merged commit 7e3637e into main Jan 14, 2026
13 checks passed
@ValerianRey ValerianRey deleted the revamp-interface branch January 14, 2026 15:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feat New feature or request package: autojac

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants